REMARKS 

Claims 1-33 remain pending in the application. Reconsideration is respectfully 
requested in light of the following remarks. 

Section 102(e) Rejection : 

The Office Action rejected claims 1, 12 and 23 under 35 U.S.C. § 102(e) as being 
anticipated by Ford et al. (U.S. Patent 5,963,947) (hereinafter "Ford"). Please note that in 
the Final Action, the Examiner refers to Ford et al. (U.S. Patent 5,963,947) as "Lehman 
('947)." Applicants, however, refer to this patent as "Ford" for clarity over Lehman et al. 
(U.S. Patent 5,974,420). Applicants traverse the rejection of claims 1, 12 and 23 for at 
least the following reasons. 

Regarding claim 1, contrary to the Examiner's assertion, Ford fails to teach that 
information usable to access a first space is provided in an advertisement for the first 
space , wherein the advertisement for the first space comprises a first schema , and 
wherein the first schema specifies one or more messages usable to invoke functions of the 
first space. Ford teaches a method, called "T Spaces" for dynamically adding 
functionality to a server that allows new operators and JAVA-based operator handlers to 
be installed on a server for future use (Ford, column 7, line 66 - column 8, line 17, and 
column 8, lines 26-35). Ford clearly does not disclose an advertisement for the first 
space that provides information usable to access the first space and that comprises a 
schema that specifies one or more messages usable to invoke functions of the first space. 
In contrast, Ford teaches that T-Spaces clients include a Tuplespace class and a 
communications library to communicate with a T-Spaces server (Ford, column 6, lines 
29-33). 

In the Response to Arguments section the Examiner includes a discussion 
regarding two different types of schemas. However, both of the types of schemas 
referred to by the Examiner are schemas that define data structures (one type of schema 
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for a data repository that describes data tables and their relationships and another type of 
schema that describes the data layout of a particular database record). Neither of these 
types of schemas have anything to do with a message schema that specifies messages 
usable to invoke functions of a space, as recited in Applicants' claimed invention. Ford's 
Tuplespace class and communication library do not involve messages usable to invoke 
functions on a space that are specified in a schema comprised in an advertisement for the 
space. Not only does Ford fail to mention anything regarding such a message schema, 
Ford also clearly fails to disclose an advertisement comprising such a message schema 
and providing information usable to access the space. 

Further regarding claim 1, contrary to the Examiner's assertion, Ford clearly fails 
to teach a client requesting creation of a second space by sending to the first space one of 
the messages specified by the first schema . As noted above, Ford does not disclose a 
schema specifying messages usable to invoke functions of a space. Instead of teaching 
that a client creates a new space by sending one of the messages specified by a schema, 
Ford teaches the use of a specific operator, NewTupleSpace(), and that such commands 
originate as a method invocation on T-Spaces client (Ford, column 7, lines 7-10 and lines 
21-30). The examiner cites the same passage of Ford (column 9, lines 34-43) that only 
describes how an operator (a command) is received from an attached client and that new 
functionality is added in response to receiving the operator. But the cited passage fails to 
disclose the receiving such an operator involves the attached client sending to the space 
one of the messages specified in a schema provided in an advertisement that provides 
information usable to access the space. Thus, Ford does not teach requesting the creation 
of a new space through the sending a message specified in a schema, but rather that Ford 
describes method invocations of Tuplespace class in a T-Spaces client. Nowhere does 
ford teach that a T-Spaces client, a Tuplespace class, or T-Spaces communication library 
would send a message specified in a schema to request creation of a new space. 

Additionally, Ford does not teach wherein the second space is initially configured 
to permit access only to the requesting client . Instead, Ford teaches only that "[ujsers can 
establish security policies by setting user and group permissions on a Tuplespace basis" 
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(Ford, column 5, lines 10-12), that indications of a client's access control privileges may 
be included as method parameters (Ford, column 7, lines 31-35), and that "only 
designated entities should have access control privileges to add new factories and 
handlers" (Ford, column 8, lines 60-63). Further, the Examiner's cited passage (Ford, 
column 9, lines 34-46) only mentions that new functionality may be added to a 
Tuplespace without mentioning anything regarding the initial access control privileges 
regarding any newly added functionality. Thus, Ford clearly fails to teach wherein the 
second space is initially configured to permit access only to the requesting client. 

Furthermore, Ford does not teach wherein information usable to access the second 
space is provided in an advertisement for the second space, wherein the advertisement for 
the second space comprises a second schema , and wherein the second schema specifies 
one or more messages usable to invoke functions of the second space. Similar to the 
discussion above regarding an advertisement for a first space, the Examiner cites column 
9, lines 43-46 that does not mention anything about an advertisement for the second 
(created) space providing information usable to access the second space and that 
comprises a second schema that specifies messages usable to invoke functions of the 
second space. In fact, the cited passage only refers to the addition of new functionality in 
T-spaces, without describing anything regarding accessing the new functionality after it 
has been created. 

For at least the reasons given above, the rejection of claim 1 is not supported by 
the prior art and its removal is respectfully requested. Similar remarks as discussed 
above in regard to claim 1 apply to claims 12 and 23. 

Section 103(a) Rejection ; 

The Office Action rejected claims 1, 5-12, 16-23 and 27-33 under 35 U.S.C. § 
103(a) as being unpatentable over Lehman (U.S. Patent 5,974,420) (hereinafter "Lehman 
'420'*) in view of Ford. 
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Lehman describes T-Spaces in an almost identical manner as Ford, but 
additionally teaches the use of a Rhonda operator for use within T Spaces wherein two 
Rhonda operators swap their tuples when their template arguments match (Lehman, 
column 8, line 65 - column 9, line 3). 

Regarding claim 1, contrary to the Examiner's contention, Lehman in view of 
Ford fails to teach accessing a first space, wherein information usable to access the first 
space is provided in an advertisement for the first space, wherein the advertisement for 
the first space comprises a first schema , and wherein the first schema specifies one or 
more messages usable to invoke functions of the first space. Since Lehman includes an 
almost identity discussion of T-Spaces as Ford, Lehman fails to overcome any of the 
deficiencies of Ford's teachings, as described above regarding the 102 rejection of claim 
1. 

Specifically, Lehman in view of ford fails to teach wherein information usable to 
access the first space is provided in an advertisement for the first space, wherein the 
advertisement for the first space comprises a first schema , and wherein the first schema 
specifies one or more messages usable to invoke functions of the first space. Lehman, 
like Ford, teaches that T-Spaces clients include a Tuplespace class and a communications 
library to communicate with a T-Spaces server (Lehman, column 4, lines 55-61). 

Also, Lehman clearly fails to teach a client requesting creation of a second space 
by sending to the first space one of the messages specified by the first schema , as the 
Examiner suggests. Lehman, like Ford, teaches the use of a specific operator, 
NewTupleSpace(), and that such commands originate as a method invocation on T- 
Spaces client (Lehman, column 5, lines 50-60). The examiner cites passages of Lehman 
that describe Lehman's Rhonda Operator that is used when two T Spaces clients 
exchange information via the T Spaces server (column 8, line 61 -column 9, line 8, and 
column 9, lines 35-48) and that include broad statements regarding how "different 
computer programming languages, database systems, operating environments, and 
operating systems" could be substituted for those described by Lehman. Neither of the 
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Examiner's cited passages refers to creating a new space by sending a message specified 
by a schema. 

Additionally, similarly to Ford, as described above regarding the 102 rejection of 
claim 1, Lehman does not teach wherein the second space is initially configured to permit 
access only to the requesting client , nor wherein information usable to access the second 
space is provided in an advertisement for the second space, wherein the advertisement for 
the second space comprises a second schema , and wherein the second schema specifies 
one or more messages usable to invoke functions of the second space. As Lehman 
teaches essentially the identical T Spaces system as Ford, the arguments above regarding 
the 102 rejection of claim 1 as applied to Ford, apply to Lehman as well. 

For at least the reasons given above, the rejection of claim 1 is not supported by 
the prior art and its removal is respectfully requested. Similar remarks as discussed 
above in regard to claim 1 apply to claims 12 and 23. 

Applicants note that the rejection of claim 5 is improper because claim 5 depends 
from claim 4 and the Examiner has not rejected claim 4 as being unpatentable over Ford 
in view of Lehman. Similarly, the rejections of claims 16, and 27 are also improper since 
they depend from claims 15 and 26, respectively, neither of which was rejected by the 
Examiner with respect to Ford in view of Lehman. 

Further regarding claim 5, Ford in view of Lehman fails to disclose a second 
client reading a service advertisement from the second space, wherein the service 
advertisement comprises information usable to execute a corresponding service. The 
Examiner does not cite any particular passage of Lehman, but instead states, "[t]o add an 
aspect of optional functionalities to [Ford] would have been obvious ... as TSpaces 
provides a powerful mechanism for inter-process communication and synchronization." 
However, Lehman's extended functionality is described as providing a mechanism for 
exchanging information between two or more processes, providing synchronous, 
anonymous rendezvous and data exchange, providing a mechanism for controlling 
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multiple processes, and providing barrier synchronization among a dynamically defined 
group of processes (Lehman, column 3, lines 21-30). Thus, while Lehman teaches that 
his Rhonda Operator can provide various means of inter-process communication, 
nowhere does Lehman describe anything regarding a second client reading a service 
advertisement from the second space, wherein the service advertisement comprises 
information usable to execute a corresponding service . 

Claim 7 was rejected "on the basis that Lehman teaches the use of different 
computer languages." At the Examiner's cited reference in Lehman states, "different 
computer programming languages ... could be substituted for those described herein" 
(Lehman, column 9, lines 10-14). Applicants assert that Lehman is referring to 
programming languages that may used to create programs, such as T-Spaces clients and 
servers, that may utilize his system and thus has no bearing on a schema that is expressed 
in a data representation language and that specifies messages usable to invoke functions 
of a space. The Examiner has responded to Applicants' previous arguments by pointing 
out the differences between a Data Manipulation Language and a Data Definition 
Language. Applicants submit however that the Examiner has misunderstood Applicants' 
argument. The issue is not whether a data representation language may be both static 
stored or dynamically created; instead, the issue is whether or not Lehman's general 
statement regarding programming languages suggests the use of a data representation 
language for a schema specifying messages usable to invoke functions of a space. 
Clearly, it does not. 

Therefore, for at least the reasons given above, the rejection of claim 7 is not 
supported by the prior art and its removal is respectfully requested. Similar remarks as 
discussed above in regard to claim 7 apply to claims 18 and 29. 

Regarding claim 8, the Examiner states that the motivation to combine XML with 
T-Spaces is noted within Lehman, "wherein the use of different computer languages is 
recognized as possible" and the Examiner further states that "as XML was in existence at 
the time of invention ... the use of the same as a programming language would have been 
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obvious." As regarding claim 7, discussed above, the Examiner's cited reference states 
that "different computer programming languages ... could be substituted for those 
described" (Lehman, column 9, lines 10-14). Lehman is referring to programming 
languages that may used to create programs that may utilize his invention and thus has no 
bearing on data representation languages, such as XML, which are used for very different 
purposes than computer programming languages. Furthermore, the Examiner's 
discussion regarding the traditional uses of XML is irrelevant. In the prior art, XML 
schema have been used to describe data structures, not to specify messages usable to 
invoke functions of a space. 

Further, neither Lehman nor Ford teaches anything regarding the use of a data 

representation language. Therefore, the combination of Lehman in view of Ford fails to 

teach or suggest any desire or benefit to using a data representation language , as the 

Examiner contends. Furthermore, the mere fact that XML was in existence at the time of 

Applicants' invention does render its use obvious as implied by the Examiner. As the 

Federal Circuit stated in In re Kotzab, 55 USPQ2d 1313, 1316 (Fed. Cir. 2000): 

Most if not all inventions arise from a combination of old elements. 
However, identification in the prior art of each individual part claimed is 
insufficient to defeat patentability of the whole claimed invention. Rather, 
to establish obviousness based on a combination of the elements disclosed 
in the prior art, there must be some motivation, suggestion or teaching of 
the desirability of making the specific combination that was made by the 
applicant. 

Therefore, for at least the reasons given above, the rejection of claim 8 is not 
supported by the prior art and its removal is respectfully requested. Similar remarks as 
discussed above in regard to claim 8 apply to claims 19 and 30. 

Regarding claims 9-11, 20-22, and 31-33 the Examiner fails to provide any 
specific reasons for his rejection of these claims. Applicants can find no reference in 
either Lehman or Ford, either separately or in combination that teaches the limitations of 
these claims and therefore respectfully request removal of these rejections. The 
Examiner only discusses combining Lehman with the ability to add functionality to a 
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TSpaces server from Ford and also with XML. Applicants fail to see the relevance of 
these combinations to the specific limitations of claims 9-11, 20-22, and 31-33. 

For example, regarding claim 9, Ford in view of Lehman clearly fails to teach 
reading a service advertisement stored in the first space , wherein the service 
advertisement comprises information which is usable to access and execute a second 
service; using the information in the service advertisement to execute the second service ; 
generating a set of results of the second service in response to the executing the second 
service; and publishing the set of results of the second service in the second space; 
wherein the requesting creation of the second space comprises requesting creation of the 
second space for storage of the set of results of the service, as the Examiner contends. 
Nowhere does Ford or Lehman teach this functionality. 

Claims 2-4, 13-15 and 24-26 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Lehman "420 in view of Oliver (U.S. Publication 2002/0133412). 
Applicants assume that the Examiner intended to reject claims 2-4, 13-15 and 24-26 
under 35 U.S.C. § 103(a) as being unpatentable over Lehman in view Ford, in further 
view of Oliver. 

Regarding claim 3, the Examiner presumably contends that Lehman in view of 
Ford in further view of Oliver teaches a client sending the root authentication token to a 
second client; the second client accessing the second space by sending to the second 
space one of the messages specified by the second schema. Applicants, however, 
disagree with the Examiner's contention. Lehman, Ford and Oliver clearly fail to teach 
sending the root authentication token to a second client and further fail to teach the 
second client accessing the second space by sending to the second space one of the 
messages specified by the second schema . 

The Examiner admits that Lehman does not teach the use of root authentication 
tokens. Ford also fails to teach the use of root authentication tokens. Oliver teaches a 
system for managing client accounts and controlling access to resources (Oliver, abstract) 
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that uses authentication tokens; however, Oliver fails to teach one client sending an 
authentication token to a second client. In contrast, Oliver teaches that an authentication 
token contains information that identifies the associated user (Oliver, paragraph 126). 
Hence, it would not make sense for a client to send such an authentication token to a 
second client, as the authentication token would not then properly identify the second 
client. 

The Examiner has responded in the Response to Arguments section that Ford and 
Lehman teach the use of keys in the form of IDs and that when combined with the 
authentication tokens of Oliver results in a system wherein the tokens of Oliver are used 
to transfer the keys of Ford and Lehman. However, the only keys taught in either Ford or 
Lehman refer to request identifiers used as keys to route responses from a T-Spaces 
server back to the originating T-Client application thread (Lehman, column 5, lines 13-23 
and Ford, column 6, lines 51-52). Additionally, the only other identifiers taught either by 
Ford or Lehman are T-Space client identifiers (Ford, column 7, lines 31-37 and Lehman, 
column 5, lines 60-65). Neither the request identifiers or T-Client identifiers can be 
transferred from one client to another as they are meaningless with respect to the other 
client and would only confuse and corrupt the T-Spaces server system or cause responses 
from the server to be misrouted. Thus, the Examiner's proposed combination of Lehman, 
Ford, and Oliver would not result in a system that comprises the requesting client sending 
the root authentication token to a second client. Instead, such a combination would only 
result in a T Spaces system that used the authentication tokens of Oliver to indicate the 
access control privileges of Ford and Lehman. 

Further, as shown above, neither Lehman nor Ford, separately or in combination, 
teach the use of a schema specifying messages usable to invoke functions of a space, nor 
do they teach accessing a space by sending messages specified in such a schema. Oliver 
teaches the use of authentication tokens, but also fails to teach anything regarding a 
schema specifying messages usable to invoke functions of a space. Thus, the 
combination of Lehman, Ford and Oliver does not teach a client sending the 
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authentication token to a second client and the second client accessing the second space 
by sending to the second space one of the messages specified by the second schema . 

Therefore, for at least the reasons given above, the rejection of claim 3 is not 
supported by the prior art and its removal is respectfully requested. Similar remarks as 
discussed above in regard to claim 3 apply to claims 14 and 25. 

Regarding claim 4, Lehman, Ford and Oliver, individually and in any 
combination, do not teach a client modifying a security policy of the second space, 
whereby the second space is configured to permit access to a second client, as the 
Examiner implies. As the Examiner has failed to cite any particular portions of Lehman, 
Ford or Oliver to support the broad statement that claim 4 is rejected in light of the 
teachings and motivations of claims 1 and 2, as they "refer to the use and manipulation of 
security measures including, but not limited to, authentication means" (Office Action, 
page 7, lines 9-12). However, any authentication means taught by Lehman, Ford and 
Oliver fails to include a requesting client modifying a security policy of a space, whereby 
the second space is configured to permit access to a second client. Ford and Lehman 
only refer to the fact that "users can establish security policies by setting user and group 
permissions on a Tuplespace basis" (Ford, column 5, lines 10-12). Oliver includes a 
system for managing client accounts and controlling access to resources over data 
networks wherein a client registered with one service provider is allowed to access the 
resources of other service providers of the system (Oliver, paragraph 17). Nowhere, 
however, does Oliver describe a requesting client modifying a security policy for a space, 
whereby the second space is configured to permit access to a second client. 

Thus, the rejection of claim 4 is not supported by the prior art and its removal is 
respectfully requested. Similar remarks as discussed above in regard to claim 4 apply to 
claims 15 and 26. 
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Claims 1-33 are further rejected as being unpatentable over Lehman '420 and 
'947, and in further view of "IBM Systems Journal, Vol. 37, No. 3" by Wyckoff, 
McLaughry, Lehman and Ford, 1998 (hereinafter "Wyckoff 5 ) 

Regarding claim 1, Applicants' arguments given above regarding Lehman in view 
of Ford regarding claim 1 apply here as well. In addition, Wyckoff presents an 
introduction to both Tuplespaces and TSpaces that is largely identical to both Lehman 
and Ford. Wyckoff fails to teach anything that overcomes the deficiencies of Lehman 
and Ford, as described herein above. The Examiner relies upon Wyckoff to teach access 
controls that include security policies. However, Wyckoff fails to disclose creating the 
second space in response to the requesting client requesting creation of the second space, 
wherein the second space is initially configured to permit access only to the requesting 
client . The Examiner cites a passage of Wyckoff that only refers to users being able to 
establish security policies by setting user and group permissions on a Tuplespace basis 
(Wyckoff, page 7, access controls). However, the fact that user can set permissions when 
establishing security polices does not suggest that when created a second space is initially 
configured to permit access only to the requesting client . 

Thus, for at least the reasons given above, the rejection of claim 1 is not supported 
by the prior art and its removal is respectfully requested. Similar remarks as discussed 
above in regard to claim 1 apply to claims 12 and 23. 

Regarding claim 2, contrary to the Examiner's assertion, Lehman in view of Ford 
in further view of Wyckoff does not teach creating a root authentication token for the 
second space; initializing an authentication service associated with the second space, 
wherein the second space is configured to permit access only to a client holding the root 
authentication token, and sending the root authentication token to the requesting client . 
The Examiner has admitted that Lehman and Ford fail to teach the user of root 
authentication tokens (Office Action, page 7, lines 4-5). Wyckoff also fails to mention 
anything regarding authentication tokens. Instead Wyckoff only refers to a general 
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ability for user and group-based access control without teaching anything about 
authentication tokens. 

Thus, for at least the reasons given above, the rejection of claim 2 is not supported 
by the prior art and its removal is respectfully requested. Similar remarks as discussed 
above in regard to claim 2 apply to claims 13 and 24. 

Regarding claim 3, Lehman in view of Ford in further view of Wyckoff fails to 
teach the requesting client sending the root authentication token to the second client and 
the second client access the second space by sending to the second space one of the 
messages specified by the second schema . Ford and Lehman, both singly and in 
combination, fail to discloses sending an authentication token to a second client, a shown 
above, and Wyckoff does not teach anything at all regarding authentication token and 
clearly does not disclose one client sending an authentication token to a second client. A 
client sending an authentication token to another client does not make sense in the 
TSpaces system, as outlined above. Furthermore, Wyckoff also fails to disclose the 
second client access the second space by sending to the second space one of the messages 
specified by the second schema. As with Ford and Lehman, Wyckoff does not mention 
anything about a schema specifying messages usable to invoke functions of a space, and 
also fails to mention a second client sending such a message to a second space. 

Thus, for at least the reasons given above, the rejection of claim 3 is not supported 
by the prior art and its removal is respectfully requested. Similar remarks as discussed 
above in regard to claim 3 apply to claims 14 and 25. 

Regarding claim 4, Lehman, Ford and Wyckoff, individually and in any 
combination, do not teach a client modifying a security policy of the second space, 
whereby the second space is configured to permit access to a second client, as the 
Examiner implies. The Examiner has failed to cite any particular portion in Wyckoff 
Lehman, or Ford, but only states that Wyckoff teaches access controls which include 
security policies. However, any access controls taught by Lehman, Ford and Wyckoff 
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fail to include a requesting client modifying a security policy of a space, whereby the 
second space is configured to permit access to a second client. The T Spaces system only 
allows users to establish security policies by setting user and group permissions on a 
Tuplespace basis (e.g. Ford, column 5, lines 10-12). Wyckoff does not include any 
additional access control features that involve a requesting client modifying a security 
policy for a space, whereby the second space is configured to permit access to a second 
client. 

Thus, the rejection of claim 4 is not supported by the prior art and its removal is 
respectfully requested. Similar remarks as discussed above in regard to claim 4 apply to 
claims 15, and 26. 

Applicants also assert that the rejections of numerous other ones of the dependent 
claims are further unsupported by the cited art. However, since the rejections of each of 
the independent claims have been shown to be improper, a further discussion of the 
rejections of the dependent claims is not necessary at this time. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and notice to that 
effect is respectfully requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5181- 
67100/RCK. 

Also enclosed herewith are the following items: 
1X1 Return Receipt Postcard 
I I Petition for Extension of Time 
I I Notice of Change of Address 

□ Fee Authorization Form authorizing a deposit account debit in the amount of $ 
for fees ( ). 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: October 15,2004 



Respectfully submitted, 




Robert C. Kowert ' 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 
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